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(57) An Element Manager Connnion Gateway Archi- 
tecture (CGA) system and method Incorporating a cli- 
ent/server architecture in which a network Element 
Management System (EMS) takes the role of "dienf 
and the protocol gateways/proxies take the role of "serv- 
er" Is disclosed. The EMS defines all protocol-independ- 
ent application logic while the gateways/proxies deal ex- 
clusively with protocol-specific knowledge. The Com* 
mon Gateway Architecture (CGA) allows the application 
logic to be shared among protocols, using a protocol in- 
dependent data model. A significant aspect of the soft- 
ware maintenance In EMS systems is that since network 
elements (NEs) use many different protocols, there ex- 



ists a diffksully and time lag associated with customizing 
a common network element manager for every network 
element using a different protocol in a given system. 
Modifications to the system typically require incorpora- 
tion of new code into the network element manager with 
associated recompilation of the entire network element 
manager subsystem. The present invention solves this 
problem by using a common gateway architecture de- 
signed to be generic across different types of network 
elements and different n^ork protocols. This pemnits 
network elements to be added incrementally without 
recompilation of the entire network element manager, 
thus reducing overall software maintenance overhead. 
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Description 

[0001 ] The present invention is related in ttie general 
area of network Element Management Systems (EMS) 
and software techniques which may be used to minimize 
the maintenance overhead of EMS when responding to 
changes in network protocols and/or incorporation of 
new/modified network elements (NE). 
[0002] As illustrated in FIG. 1 , the present invention 
may have application In situations where there are one 
or more telecommunications networks (01 1 0, 01 20) that 
may or may not contain equipment from different ven- 
dors. The network equipment elements (N E) used within 
these networks (0115, 0116, 0125, 0126) may take 
manyfomns, including but not llmitedto switch gear, mul- 
tiplexersi and the like. These network elements (0115, 
Oil 6, 0125, 0126) are generally under control of one or 
more computer systems (0111,0121) that are controlled 
by computer software (0112, 0122) that may be stored 
on a variety of storage media. This computer software 
generally takes the form of one or more network element 
managers (0113, 0114, 0123, 0124) that control and 
monitor the network elements (01 15,011 6, 0126. 01 26) 
that comprise constituent components of the telecom- 
munk^ation networks (0110, 0120). 
[0003] The present invention deals specifically with 
Innplementations of the network element manager 
(0113. 0114, 0123. 0124) as they relate to the overall 
control and monitoring of the various network elements 
(0115, 0116, 0125, 0126) within the context of one or 
more telecommunications networks (Oil 0, 0120). 

Abbreviations and Definitions 

[0004] To minimize the verbosity of this document, a 
variety of abbreviations and definitions will be provided 
to aid the reader. This information may be applicable to 
the prior art, the present invention, or some combination 
of the two. No assumption shoukJ be made regarding 
the applicability of this information except as referenced 
within the applicable preferred embodiment description 
of the present invention as given later in this document. 

List of Abbreviations 

[0005] The following acronyms will be used through- 
out this document: 

AID Native Identifier for TL1 objects 

AMC Alcatel Management Console 

AMV ALMAP View (GUI Framework) 

API Application Programming Interface 

AS/ASM Alarm Surveillance Manager 
ANS Ak^atel Network Systems 
ASN.1 Abstract Syntax Notation 1 
CGA Common Gateway Architecture 
CORBA Common Object Request Broker Architec- 
ture (See Understanding CORBA by Randy 



10 



CMIP 



15 CMISE 





CRB 




DDTS 




Dll 


20 


DME 












crvi w 






25 






uUI IVI 




GEM 
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GW 
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IM 




lOR 




IP 




LIT 




LOC 


40 


LTN 




MIB 




MSAN 




NE 




NML 


45 


NMS 




NVP 




OAD 




OMG 




OS 


SO 






OVE 




PNM 




PY 


55 


Q3 




RON 




RTC 



Otte. Paul Patrick, and Mark Roy, (ISBN 
0-13-469884'g, 1996); Object-Oriented 
Frameworks Using C++ and CORBA by 
Vishwajit Aklecha (ISBN 1-57610-403-6. 
1999); Advanced CORBA Programming 
with C-I-+ by Michi l-ienning and Steve 
Vinoski (ISBN 0-201-37927-9, 1999); 1998 
OMG PDF document 'The Common Object 
Request Broker: Architecture and Specifi- 
cation" at ftp://ftp.omg.org/pub/docs/for- 
mal/98-12'01 pdf for a complete specifica- 
tion of the CORBA system). 
Common Management information Proto- 
col 

Common Management Information Service 
Element 

Change Review Board 

Fault Report System 

Dynamic Invocation Interface 

Distributed Management Environment 

Distinguished Name (name in a NVP) 

Element Management Layer 

Element Management System 

Functional Access Domain 

Fully Distinguished Name 

Guidelines for the Definition of Managed 

Objects 

Generic Element Manager 

Gateway/Proxy 

Graphical User Interface 

Gateway 

HP Open View 

Interface Description Language 
Interface Description Language 
Information Model 
Interoperable Object Reference 
Internet Protocol 
Local Integration Test 
Lines of Code 
Local Transport Networks 
Management Infomnation Base 
Multl Service Access Node 
Network Element 
Network Management Layer 
Network Management System 
Name-Value Pair 
Object Access Domain 
Object Management Group 
Operations System (e.g. Network Manage- 
ment Applrcation) 

Approved instructions for engineering activ- 
ities 

Physical Network Manager 
Person Years 

An object-oriented network management 
protocol 

Relative Distinguished Name 
Real Time Clock 
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SDH Synchronous Digital Hiorarchy 

S IT Systenn I ntegrati on Test 

SITC SIT completed 

SIWF System Management Framework 

SNMP Simple Networtc Management Protocol 

SONET Synchronous Optica) Network 

SQL Structured Query Language 

SVT System Validati on Test 

SW Software 

TLD Top Level Design 

TL1 Transaction Language 1 

UML Unified Modeling Language 

X25 A communications protocol 



[0006] These acronyms must be interpreted within 
their context as describing either the prior art (in some 
contexts) or the present invention and Its embodiments. 
Some terms will apply to both the prior art and the 
present invention while others may apply to one or nei- 
ther of these. 

Definitions 

[0007] The following definitions will be used through- 
out this document in describing the prior art as well as 
the present invention and its embodiments: 

• Fine-grained model - an object-oriented model In 
which there is an object instance for each entity in 
the problem domain. A fine-grained model typically 
defines an object class for each entity type in the 
problem domain and deals with lots of object in- 
stances (thousands to millions of objects). Refer- 
ence FIG. 16 (1603) for a typical example of this 
model. 

• Coarse-grained model • a semi-object-oriented 
model in which there is only a very limited amount 
of object instances. A coarse-grained model typical- 
ly only defines a limited number of object classes 
and deals with a very limited number of object in- 
stances (tens of objects). Reference FIG. 1 6 (1 602) 
for a typical example of this model. 

• Facade object - an object that acts as a front (or 
shell) for dispatching requests to an actual modeled 
object A fagade object is the key towards the defi- 
nition of coarse-grained modules. 

• Hierarchical model - an object oriented model in 
which parent-child relationships are defined. Refer- 
ence FIG. 16 (1601) for a typical example of this 
model. 

• Fully Distinguished Name - a unique identifier for 
objects in hieranshical object modules. A FDN is a 
sequence of Relative Distinguished Names 
(RDNs). An RON is a name-value pair (NVP) in 



4 

which the name Is commonly referred to as the Dis- 
tinguished Name (DN). Each child of the same par- 
ent has a unique RON. In other words, each RON 
is unique within its parents context. 

5 

» Object View - the definition of the (sub)set of at- 
tributes and the ($ub)set of operations visible on the 
object. Different views on the same object have a 
different set of attributes and/or a different set of op- 
10 orations available on the object. 

Background of the Invention 

Overview 

IS 

[OOOB] Network elements (NE) (0115. 0116. 0125, 
0126) as Illustrated In FIG. 1 generally make use of 
many different communication protocols. This diversity 
in communications protocols increases the difficulty and 

£0 time to customize a common network element manager 
system (EMS) (0113. 0114, 0123, 0124) for every net- 
work element using a different protocol in the system. 
For example, Incorporating the individual protocols with- 
in the EMS gonoraliy increases the overall subsystem 

25 complexity, increases code size, probability of software 
error/failure, and compilation time. Thus, as ilJustrated 
in FIG. 2, the current state of the art is to incorporate 
each network element protocol (TL1 . 'SNMP, Q3, etc.) 
within each EMS (0210, 0220, 0230). These protocols 

30 (0211 , 0221 , 0231 ) are then used to communicate with 
the various protocoi-specifk: network elements (0212. 
0213. 0222. 0223. 0232. 0233). 

EMS Software Development 

35 

[0009] Prior to the present Invention, as illustrated in 
FIG. 2 the code of the network manager system (EMS) 
(0210. 0220. 0230) had to be revised and recompiled 
for each different protocol (0211, 0221, 0231) used by 

^ a networi< element (0212, 0213, 0222, 0223, 0232, 
0233). Software developers maintaining EMS had to be 
very knowledgeable of the network element manager 
code and the stmcture of this system in order to make 
any necessary revisions to the software code. Thus, the 

45 level of software developer expertise in the prior art is 
significant and nontrivlai. and the amount of time re- 
quired to implement changes to the EMS is significant. 



[0010] As illustrated in FIG. 2, a common software 
configuration implementing a network management 
function may include numerous Element Management 
System (EMS) components (0210, 0220. 0230) each of 
55 Which implennents a different protocol (TL1 , SNMP, Q3. 
etc.) (0211 . 0221, 0231 ). These protocols (0211 . 0221 . 
0231) are Integrated into each EMS component (0210. 
0220, 0230) and constitute a combined Application Log- 
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icand Protocol Layer (0240). 
[0011] The rationale for various EMS embodiments 
(021 0, 0220, 0230) is that the protocols they imptement 
(TL1 . SNMP. Q3. etc.) (0211 , 0221 , 0231) are necessary 
to support a variety of network switching and multiplex- 
ing equipment (0212, 0213, 0222, 0223, 0232. 0233) 
that by necessity or implementation requires a specific 
conrtmunicBtion protocol. This Network Element (NE) 
layer (0250) may incur significant changes as new 
equipment is added and/or removed and new protocols 
or protocol extensions are incorporated in the various 
network elements (0212, 0213, 0222, 0223, 0232, 
0233). 

[001 2] As each of these network changes is incurred, 
the ElVIS software must be recompiled with each new 
protocol change to Incorporate this new network man- 
agement functionality into the overall system. This cre- 
ates a significant burden on software management per- 
sonnel, as the tight integration of the application logic 
and the network element protocol layer within the EMS 
makes this system difficult to mcuntaln and prone to er- 
rors in software development and maintenance. 

Objects of the Invention 

[0013] Accordingly, the objects of the present inven- 
tion are (among others] to circunwent the deficiencies 
in the prior art and affect the following objectives: 

(1 ) To reduce software maintenance overhead as- 
sociated with Element Management Systems. 

(2) To enable Element Management Systems to be 
augmented with additional Network Elements with- 
out the need for recompilation. 

(3) To minimize the complexity of Element Manage- 
ment Systenns so as to increase their reliability and 
ease of software maintenance. 

(4) To reduce the time needed to Implement chang- 
es to an EMS. 

(5) To permit changes to be made to the EMS by 
software developers with a reduced skill set. 

(6) To permit implementation of network elements 
from a variety of vendors into a single EMS. 

[0014] While these objectives should not be under- 
stood to limit the teachings of the present invention, in 
general these objectives are achieved in part or in whole 
by the disclosed invention that is discussed In the fol> 
lowing sections. One skilled in the art will no doubt be 
able to select aspects of the present Invention as dis- 
closed to affect any combination of the objectives de- 
scribed atmve. 



Brief Summary of the Invention 
Overview 

5 [0015] Referencing FIG. 3. the present invention can 
t)est t>e illustrated in terms of an exemplary network 
management applicatk>n in which a wide variety of ap- 
plteations, such as Alarni Sun/eillance Manager (AS, a 
NML-layer application that allows one to monitor, ao- 

f 0 knowledge, and resynchronize alarms sent by a collec- 
tion of NEs) (0301). Physical Network Managers (PNM. 
a NML-layer application that allows a network adminis- 
trator to add/delete and supervise/unsupervised NEs) 
(0302), and the like along with their possible interface 

15 adapters (0313). In this scenario one or more Generic 
Element Manager Systems (GEM/EMS) (0311, 0312) 
communicates with a Generic Element Manager Appli- 
cation Senrer subsystem (0321 ) via a standard software 
interface such as CORBA (0320). The GEM Application 

^ Server (0321 ) then communicates over an internal API 
(0330). This API is then interfaced to one or more ge- 
neric protocol proxies (0331 , 0332) that then communi- 
cate with the network elements (0351 , 0352) via a net- 
work element protocol specific interface (0341 , 0342). 

2s [0016] The architecture of the system illustrated in 
FIG. 3 differs significantly as compared to the prior art 
in that the GEM/EMS Application Sen/er (0321) along 
with the associated internal API interface (0330) and ge- 
neric proxies (0331 , 0332) represent a new paradigm in 

30 the implement of network element management to con- 
trol, supervise, and nrtonrtor the various network ele- 
ments (0351 . 0352) via a wide variety of network ele- 
ment specifk; protocols (0341 , 0342). 



[QOIT] Briefly, the invention Is a system pemnitting a 
network Element Management System (EMS) to be 
maintained and modified without the huge software 
overhead of supporting a plethora of network protocols 
that are targeted towards a variety of network elements 
(NE). 

[0018] As illustrated in FIG. 4, the present invention 
solves the problem present in the prior art by using a 
common gateway architecture (CGA) (0401) driven by 
an EMS (0400) designed to be generic across different 
types of network elements and different network ele- 
ment protocols. The architecture is best described as 
client/server based with a gateway/proxy (GP) layer 
(0450) that contains the protocol specific generic gate- 
ways. The GP layer (0450) is not required to have any 
specific network element knowledge but instead just 
needs to know the protocol used to communicate with 
the network elements (0412, 041 3» 0422, 0423. 0432, 
0433). The GP layer (0450) fomiats requests from the 
server layer (0440) into protocol specific requests and 
translates the protocol -specif k: responses into server 
objects/attributes. The GP layer (0450) is the only conv 



35 Generic Element Manager System (GEM/EMS) 
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ponent directly interfacing with the networic elements 
(0412. 0413. 0422, 0423, 0432. 0433) to setup or dose 
connections, send commands and receive responses 
and monitor for events/alamis. 

5 

Brief Description of the Drawings 

[0019] for a fuller understanding of the advantages 
provided by the invention, reference should be made to 
the following detailed description together with the ac- io 
ccmpanying drawings wherein: 

FIG 1 illustrates an exemplary architectural over- 
view of how the present invention interfaces into an 
integrated multi-vendor network management sys- is 
lom incorporating computer monitoring, configura- 
ton and the like via software control; 

FIG 2 liiustrritcs an architectural overview of the pri- 
or M't ar>d iHusif ates the connectivity t^etween tradh 20 
tion<il «tn Element Management System (EMS) and 
thctf Mssocwtlcd Network Elements (NE); 

FIG 3 iHustnitcs an exemplary architectural soft- 
Wrtro ovofviow of the present invention and illus- ^5 
tratos the connectivity between the disclosed Ge- 
neric Eiencn! Management System (GEM/EMS) 
and tt>e Associated Network Elements (NE) via ge- 
neric proxies 

30 

FIG 4 iliusirates a presently preferred embodiment 
of the invention illustrating how the Element Man- 
agement System (EMS) is augmented with a Com- 
mon G«4ieway Architecture interface (CGA) to pro- 
vide a generic gateway/proxy (GP) interface; 35 

FIG 5 Illustrates an exemplary system block dia- 
gram of the server architecture used within the 
present invention; 

40 

FIG 6 illustrates an exemplary system block over- 
view dwgram of the gateway/proxy (GP) interface 
moduto and its general functionality; 

FIG 7 lUustraics an exemplary system block dia- 45 
gram of me gaieway/proxy (GP) interface module 
and lis Mssocialed session and presentation layers; 

FIGS illustrates an exemplary CGA interface spec- 
ification (1/2); so 

FIG. 9 illustrates an exemplary CGA interface spec- 
ification (2/2): 

FIG 10 illustrates an exemplary RESPONSE data ss 
structure: 

FIG. 11 illustrates an exemplary base object class 



definition; 

FIG . 1 2 illustrates an exemplary architecture for the 
common domain server utilized in the present in- 
vention, and shows that the layered organization al- 
lows one to reuse the implementation or overload 
the implementation of the upper layers, therefore 
reducing the overall domain server code size while 
remaining flexible enough to support a variety of 
networic element types/releases/protocols; 

FIG. 13 Illustrates an exemplary embodiment of the 
client architecture utilized in the present invention; 

FIG. 14 illustrates an exemplary deployment of the 
present invention and shows a variety of control and 
management relationships between the various 
network elements; 

FIG. 15 Illustrates an exemplary naming service 
registration and naming policy associated with the 
present invention; 

FIG. 16 illustrates prior art differences between 
coarse grained and fine grained models that may 
be used in some implementations of the present in- 
vention; 

FIG. 17 illustrates an exemplary system block dia- 
gram of an exemplary complement of functions 
comprising one embodiment of the present inven* 
tion; 

FIG. 18 illustrates an exemplary system flowchart 
illustrating an Add Network Element function; 

FIG. 19 illustrates an exemplary system flowchart 
illustrating a Remove Network Element function; 

FIG. 20 illustrates an exemplary system flowchart 
illustrating a Configure Gateway function; 

FIG. 21 illustrates an exemplary system flowchart 
illustrating a Set Network Element Address func- 
tion; 

FIG. 22 illustrates an exemplary system flowchart 
illustrating a Connect to Network Element function; 

FIG. 23 illustrates an exemplary system flowchart 
illustrating an Disconnect from Networi< Element 
function; 

FIG. 24 illustrates an exemplary system flowchart 
Illustrating a Connectivity Poller / Ping Cycle func- 
tion; 

FIG. 25 illustrates an exemplary system flowchart 
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illustrating a Register Autonomous Message Call- 
back function; 

FIG. 26-27 illustrates an exemplary system flow* 
chart illustrating a Send Command to Network Ele- 5 
ment function; 

FIG. 28-29 Illustrates an exemplary system flow- 
chart illustrating a Retrieve Command Response 
from Network Element function; io 

FIG. 30 illustrates an exemplary system flowchart 
illustrating a Request Thread Processing function. 

Description of the Presently Preferred Exemplary is 

Embodiments 

[0020] While this invention is susceptible of emt^odi- 
ment In many different forms, there Is shown in the draw- so 
ings and will herein be described in detailed preferred 
embodiment of the invention wrth the understanding that 
the present disclosure is to be considered as an exem- 
plification of the principles of the Invention and is not 
Intended to limit the broad aspect of the Invention to the 2S 
embodiment illustrated. 

[0021] The numerous innovative teachings of the 
present application will be described with particular ref- 
erence to the presently preferred embodiment, wherein 
these innovative teachings are advantageously applied so 
to the particular problems of an ELEMENT MANAGER 
COMMON GATEWAY ARCHITECTURE SYSTEM AND 
METHOD, However, it should be understood that this 
embodiment is only one example of the many advanta- 
geous uses of the innovative teachings herein. In gen- ss 
eral, statements made in the specification of the present 
application do not necessarily limit any of the various 
claimed inventions. Moreover, some statements may 
apply to some inventive features but not to others. 



Definitions 

[0022] Throughout the discussion in this document 
the following definitions will be utilized: 

System Blocks / Procedural Steps Not Umltive 



40 



43 



[0023] The present invention may t>e aptly described 
in temns of exemplary system block diagrams and pro- 
cedural flowcharts. While these items are sufficient to so 
instruct one of ordinary skiil in the art the teaching of 
the present invention, they should not be strictty con- 
strued as limiting the scope of the present Invention. 
One skilled in the art will be aware that system block 
diagranns may be combined and rearranged with no toss 55 
of generality, and procedural steps may be added or 
subtracted, and rearranged in order to achieve the same 
effect with no loss of teaching generality. Thus, It should 



be understood that the present invention as depicted in 
the attached exemplary system block diagrams and pro- 
cedural flowcharts is for teaching purposes only and 
may be reworked by one skilled in the art depending on 
the intended target application. 

Personal Computer Not Ltmitive 

[0024] Throughout the discussion herein there will be 
examples provided that utilize personal computer (PC) 
technok>gies to illustrate the teachings of the present 
invention. The term 'personal computer' should be given 
a broad meaning in this regard, as in general any com- 
puting device may be utilized to Implement the teach- 
ings of the present invention, and the scope of the in- 
vention is not limited just to personal computer applk»- 
tlons. 

Internet/Intranet Not Limltive 

[0025] Throughout the discussion herein the terms In- 
ternet and Intranet wiil be used generally to denote any 
network communication system or environment. Gener- 
ally the term Intranet will denote connmunk^tions that 
are local to a given system or user, and Internet will de- 
scribe communications In a more distant local. One 
skilled in the art wQI recognize that these temns are ar- 
bitrary within the contexts of modern communk^ation 
networks and in no way limltive of the scope of the 
present invention. 

[0026] The present invention specltteally anticipates 
that In some implementations the GUI development 
framework (and/or its runtime component) will commu- 
nicate with the data used to drive the GUI over the In- 
temet. Thus, the application driving the user interface 
may reside on one computer system and the data used 
for presentBtton and control may be contained some- 
where else on another computer system and t>e ac- 
cessed via any number of networking protocols. 

Applk^atlon Programming Interface (API) Not Limitive 

[0027] While the present Invention may be In part Im- 
plemented using standard Application Programming In- 
terfaces (APIs) such as Software Development Kits 
(SDKs) and the like, there Is no requirement that the 
present Invention be implemented using these tools. 

Operating System Not Limitive 

[0028] Additionally, while the present invention may 
be implemented to advantage using a variety of Micro- 
soft® operating systems (irxsluding a variety of Win- 
dows^M variants), nothing should be construed to limit 
the scope of the Invention to these particular software 
components. In particular, the system and method as 
taught herein may be widely implemented in a variety of 
systems, some of whrch may incorporate a graphical us- 
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er interface. Some examples of these include HP-UX^*", 
LINUX^", SOLARIS, and UNIX^"* (and its variants), 
among others. 

Data Structures Not Limitive 

[0029] The present invention may be embodied in a 
variety of data structures in some preferred embodi- 
ments. However, the form of such data structures as de- 
scribed herein is only exemplary. One skilled in the art 
would quickly realize that a wide variety of other data 
structures could be used equivalently in this applk:ation. 
Therefore, no data structure contained herein should be 
interpreted as limiting the scope of the present inven- 
tion. 

Oven^iew 

[0030] As illustrated in FIG. 4, the present invention 
utilizes a Generic Element Management System (GEM/ 
EMS) (0400) that interfaces with a Common Gateway 
Architecture (CGA) (0401) that communicates with a va- 
riety of generic proxies (0410, 0420. 0430, etc.). These 
proxies (0410, 0420, 0430] then communicate in a pro- 
tocol-epecific manner (0411 , 0421 , 0431) with a variety 
of network elements (0412» 0413, 0422, 0423, 0432, 
0433) that may be from a variety of equipment vendors. 
The strength of this architecture lies in the ability to com- 
municate with equipment of a variety of vendors without 
having to specifically code (and maintain) this support 
in the EMS (0400). 

[0031] Referencing FIG. 4, the Common Gateway Ar- 
chitecture (CGA) (0401) is a client/server architecture 
in which the Element Management System (EMS) 
(0400) lakes the role of "client" and the protocol gate- 
ways/lproxies (041 0, 0420, 0430) take the role of "serv- 
er. The EMS (0400) defines all protocol-independent 
application logic while the gateways/proxies (0410, 
0420. 0430) deal exclusively with protocol-specific 
knowk^dge. 

[0032] Generally, the present invention uses one pro- 
tocol gateway/proxy per Network Element protocol 
(0411. 0421, 0431). The CGA (0401) defines a generic 
protocol-independent interface between client (EMS) 
(0400) and server (gateway/proxy) (041 0, 0420, 0430), 
the CGA Interface (0401). In other words, each protocol 
gateway/proxy (0410, 0420, 0430) needs lo implement 
this generic interface. 

[0033] From FIG. 4, It is clear that the present inven- 
tion can be thought of as incorporating an Application 
Layer (0440), a Gateway/Proxy Layer (0450), and a Net- 
work Element Layer (0460). Since the Application Layer 
(0440) in the present invention is represented as a Serv- 
er, with corresponding Client functionality being incor- 
porated in the Gateway/Proxy Layer (0450), the follow- 
ing discussion will detail these elements and how they 
interact. 



EMS Application Server Architecture (0500) 

[0034] FIG. 5 illustrates an exemplary embodiment of 
the EMS Application Server Architecture (0500) . The ar- 
s chitecture (0500) can be split up into three logical parts: 
the Sen/er Plug-in Framework (0510), the Domain Serv- 
ers (0520) and a collection of Standard Generic Servic- 
es (0530) available to all domain servers. 

10 Server Plug-in Framework (051 0) 

[0035] The Server Plug-in Framework (0510) allows 
for subcomponents (I.e. functional domain managers) 
to be plugged into the system. 

15 [0036] The components that are available in the sys- 
tem are read from a Supported Domains configuration 
file (SupportedDomalns.properties) (0511). As different 
types of NetworK Elements possibly support different 
subsets of Network Management functions, the Sup- 

^ ported Domains configuration file is indexed by NE type 
and release and Is consulted each time a new NE in- 
stance is added to the system. 

[0037] When a request to perform a certain NM func- 
tion comes in, the responsible domain server is looked 
25 up and when no such server is available for the given 
NE instance, an OperationNotSupported exception is 
thrown by the system. 

Domain Managers (Ptug-lns) (0520) 

30 

[0038] Domain Managers (plug-ins) (0520) provide 
specific NM functionality for their domain. Each domain 
manager has its own name space and possibly shares 
(or provides access to) parts of his name space with oth- 

35 er domain managers. Domain managers are also re- 
ferred to as domain servers or domain servants. 
[0039] Illustrated in FIG. 5 are exemplary domain 
sewers (0520) including Equipment (0521), Facility 
(0522), Cross-connection (0523), Test Access (0524), 

40 PM (0525), System Maintenance (0526), Alarm (0527), 
and NE Directory (0528) Managers. One skilled in the 
art will recognize that a wide variety of other plug-ins 
(0529) are also possible and supported by this architec- 
ture. 

45 

Standard Generic Servtees (0530) 

[0040] Standard Generic Services (0530) generally 
includes a collection of servk^es available to all domain 

50 managers. 

[0041] The Persistency Service (0531 ) provides a re- 
pository for persistent data, like the list ofNEs to be man- 
aged by the server with all the necessary address infor- 
mation to contact each NE. 

55 [0042] The Event Handler (0533) listens for autono- 
mous messages coming from the different N Es. and dis- 
patches those messages internally towards the relevant 
domain manager (alarm manager, database change 
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handier. 

[0043] The Command Dispatcher (0534) Interacts 
with the protocol specific gateway/proxy for sending 
commands to and receiving responses from the target 
Network Element. 

[0044] The Session Manager (0536) maintains infor- 
mation (operator profile) about each client connected to 
the server. It builds Session CORBA objects for each 
client. Clients then use their dedicated Session object 
to obtain a reference to their dedicated domain manag- 
ers. 

[0045] The Security Manager (0536) limits the actions 
available to a particular client on an individual object or 
group of objects. The security manager Interfaces with 
the security database (0537). This datat)ase contains 
Object Access Domains (OAD) and Functional Access 
Domains (FAD) associated with operator profiles. 
[0046] The Management Information Base (MIB) 
(0538) is a collection of objects used In the request rout- 
ing pn3cess, i.e. the process of forwarding incoming re- 
quests to the right domain manager for domain specific 
processing. The MIB acts as a cache for subsequent 
requests to those domain managers that keep (parts of) 
their name space in memory (e.g., the equipment do- 
main manager). The MIB provides convenient object re- 
trieval/storage functionality. 

Gateway/Proxy Layer Overview (0600) 

[0047] Referencing the Gateway/Proxy Layer High 
Level Overview in FIG. 6, the gateway/proxy layer 
(0450) consists of proxies (0610) that format requests 
(0620) from the EMS (0400) application logic layer 
(0440) into protocol-specific requests (0640) and trans- 
lates the protocol-specific responses (0630) Into appli- 
cation logic layer (0440) objects/attributes for use by the 
EMS. The gateway/proxy layer (0450) is the only com- 
ponent directly interacting with the network elennents (at 
the network element layer (0460)) to setup or ciose con- 
nections, to send commands and receive responses 
and to monitor for autonomous messages (alarms and 
events). 

[0048] The architecture depicted in FIGs. 3, 4, and 6 
contrasts with the PRIOR AFCT architecture illustrated in 
FIG. 2 in that in the PRIOR ART architecture the appli- 
cation logk: Is network element protocol dependent This 
means that all application logic needs to be revised (or 
event completely rewritten) when a new protocol Is add- 
ed to the network. 

[0049] The Common Gateway Architecture (CGA) Il- 
lustrated in FIG. 6 allows the application logic (0400, 
0440) to be shared among protocols, using a protocol 
Independent data model, also called a Management tn- 
fonmation Base (MIB). It is the responsibility of the pro- 
tocol gateways/proxies (0410. 0420, 0430, 0610) to 
translate the data structures the MIB Is built up with, Into 
protocol-specific data structures (0640) and vice versa. 
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Gateway/Proxy Anchttecture Connponents (0700) 

[0050] FIG. 6 illustrates an exemplary high-level ar- 
chitecture (0700) common to all protocol gateways/ 
5 proxies (061 0) and illustrates an exemplary set of com- 
ponents comprising same. Each gateway/proxy (0610) 
is protocol specific, but network element implementation 
independent. The gateway/jsroxy requirements are: 

10 • Manage the connections to the network elements. 
Including automatically re-establishing connections 
when they get lost (0616). 

• Match network element responses with EMS re- 
15 quests, including congelation of linked replies 

(0614) . 

• Parse (0612) and repon autonomous messages 

(0615) . 

20 

• Be network element independent (0612). 

• Support multiple network element connections at 
the same time (0616). 

25 

• Be multi-threaded to handle multiple commands at 
the same time. 

• Implement the CGA i nterface (061 1 ) . 

30 

[0051] The protocol parserAranslator (0612) merely 
defines the syntax of the commands, the responses and 
the autonomous messages. Each network element 
however defines the semantk:s of the commands, their 

35 input arguments and their result (output). These cfiffer- 
ences between network elements are handled in NE 
type and release dependent configuration files, stored 
in the protocol dk:tionary (0617). 
[0052] For each network element type/release, the 

40 protocol dkJtionary (0617) stores all command tem- 
plates and the rules to parse Individual object attributes 
out of connmand responses and autonomous messag- 
es. Command templates are the actual commands in 
the right syntax with placeholders for the command-in- 

^ put arguments. The rules to parse Individual object at- 
tributes out of command responses and autonomous 
messages are regular expressions In case of the TL1 
protocol. In case of the Q3 protocol, the dictionary im- 
plements the Q3 GDMO model and the attributes are 

^ Immediately available as attributes on the managed ob- 
jects defined in the GDMO model, with AS N.I syntax. 
One skilled in the art will quickly realize that a wide va- 
riety of protocols exist and that for each of these sup- 
ported by the CGA. there must exist corresponding 

S5 translation tables within the protocol dictionary (061 7). 
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CGA Interface Description 

[0053] The generic interface between EMS and pro- 
tocol gateways/proxies can be defined in the program- 
ming language of choice, or even in IDL, depending on 
the overall system requirements. An exemplary embod- 
iment of this interface may be defined in Java as Illus- 
trated in FIGs. e-9. 

[0054] The definition of Address and all exceptions is 
left unspecified. A Name AndString Value structure is the 
representation of a name-value pair in which both the 
name and the value are of type String. An AttributeValue 
structure is the representation of a name-vatue pair in 
which the name is of type String and the value Is of type 
org.omg.CORBA.Any. An object of type org.omg.COR- 
BA.Any can represent any type defined in IDL. The rea- 
son for using CORBA structures at this level is to avoid 
structure translation from EMS MIB to clients. 
[0055] The Response object is the protocol independ- 
ent object used for passing Infomnation from gateway/ 
proxy to the EMS. An example Response data structure 
could be as simple as the exemplary listing illustrated in 
FIG. 10. 

[0056] The above data structure resembles the defi- 
nition of an SQL database table. The fields are Any 
structures and can therefore contain any pre-defined 
IDL data structure. The unique identification of each ob- 
ject in the response is included as one of the columns 
In this table. I n case of the TL1 protocol, this unique Iden- 
tifier will be an AID; rn case of the Q3 protocol, the unique 
identifier is an FDN. The EMS MIB has a mapping func- 
tion to translate these unique identifiers into internal 
unique object identifiers. Typically, this mapping func- 
tion is NE dependent. 

[0057] The commandid argument in the sendCom- 
mandO function is the unique identification for the action 
to be executed in the network element. The protocol 
gateway/proxy searches for this commandid in the pro- 
tocol dictionary for the given network element type and 
release and finds the command template associated 
with this Identifier 

[0058] Ideally, command identifiers are logical Identi- 
fiers corresponding to high-level actior>s available in all 
network elements, no mauer what their protocol is. Ex- 
amples of such logical identifiers are: get, set, delete, 
create, login and logout. However, In order to provide 
100% manageability, most of the command Identifiers 
will be network element specific. 
[0059] The entityld argument in the sendCommand() 
function is the unique identification of the target object 
in the network element for the action. In order to support 
hierarchical network element models, the entityld takes 
the f omn of a Fully Distinguished Name (FDN) structure. 
An FDN is a sequence of Relative Distinguished Names 
(RDNs). An RDN is a name-value pair in which the name 
is commonly referred to as the Distinguishing Name 
(DN). Each child of the same parent has a unk)ue RDN, 
in other words: each RDN is unique within its parenfs 



context. 

[0060] The InArgs argument in the sendCommandQ 
function coTSsponds to the list of arguments of the com- 
mand. The protocol gateway/proxy replaces each 

^ placeholder in the command template, with the value of 
the corresponding argument in the argument list. 
[0061 ] The outArgs argument In the sendCommand() 
function corresponds to the list of attributes to be re- 
turned by the command. Only the given attributes will 

^0 appear in the Response structure. 

Protocol Independent Data Model 

[0062] The Element Management System's internal 
15 object model needs to be protocol independent. More 
specifically, this requirement means the model needs to 
be able to store any number of attributes of any possible 
type. One way this can be achieved Is by storing at- 
tribute-value pair lists, in which the value is of type org. 
^ omg. CORBA. Any. In a generic object class from whrch 
all other MIB object classes inherit. Specialization can 
be applied to better organ ize object functionality, hence 
facilitating the Implementation of the application logic. 
[0083] An example base object class definition is il- 
lustrated In FIG. 11. All member functions have inten- 
tionally been left out. 

Common Domain Server Architecture (1200) 

30 [0064] This section describes a design pattern (as il- 
lustrated in FIG. 12) that may be used to broadly exem- 
plify embodiments of the present invention (as opposed 
to providing an exemplary actual implementation). Each 
domain server uses this design pattern (1200) as a 

35 guideline for implementation, the details of which are de- 
scribed separately in this document. 
[0065] FIG. 12 illustrates a typical domain server 
Each domain server supports the Plug-In interface. This 
interface includes functions to: 

40 

• Add / remove NEs from the system 

• Starting / stopping the supervision of an N E 

45 [0066] Generally each domain server publishes the 
following open CORBA Interfaces: 

• Specific EML Interface - this is a strongly typed in- 
terface for functionality that is domain specific, but 

^ NE type and release independent. Support of a spe- 
cify EML interface is optional. A pointer to the COR- 
BA object instance implementing this interface is 
obtained from the Session CORBA object instance. 

55 • Generic EML Interface (Navigator) (used to obtain 
100% manageability) - this is a weakly typed inter- 
face that provides a way to access a fine grained 
object model through a coarse grained IDL inter- 
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face. It basically consists of a browser (Navigator) 
for traversing a hierarchical object model and for 
discovering each objects attributes and supported 
functionality. A pointer to the CORBA object in- 
stance implementing this interface is obtained from 
the CORBA object instance implementing the spe- 
cific EML interface. 

• Generic NML Interface (ECOM) - this is the inter- 
face used by higher level NML applications. The in- 
terface is NE type and release independent. The inrv 
plementation of the interface is done in terms of the 
implementation of the EML Interfaces. 

In order to avoid substantial rework when a new NE type 
is introduced to the system, the domain server's Imple- 
mentation uses a layered approach. As much of the NE 
specifics as possible are isolated In NE specific config- 
uration files, but there are always situations where this 
static way of handling specifics is simply not possible or 
not practical. In those situations, object specialization 
(inheritance) is applied and an object factory is used to 
instantiate the right version of the object's implementa- 
tion, given its NE type and release. 
(0067) The following layers can be distinguished with- 
in the domain server (1200): 

• Frannework Layer (1210) - this includes the inter- 
face a domain servant needs to support In order to 
be manageable by the server framework. The plug- 
in interface defines the functions addNE, deleteNE, 
starts upervision and stopSupen^lsion. The imple- 
mentation depends on the domain sen/ant. The 
Navigator Interface is the generic interface through 
which the domain servant's name space can be dis- 
covered^ including the functionality supported by 
each individual object In that name space. 

• Domain Layer (1 220) - this layer is domain specifto, 
but protocol^ E type and NE release independent. 
It includes the imptementation of the optional do- 
main specific interface. This layer can work with na- 
tive identifiers, but cannot interpret the value of the 
native identifier as this is protocol specific. 

• Protocol 1-ayer (1 230) - this layer is only domain and 
protocol specific. It doesn't include any NE specif- 
ics, but can deal with protocol speclfk; concepts, like 
AlOs in case of the TL1 protocol. 

• Type Layer (1240) - this layer implements all NE 
specifics for the given domain. It doosnt deal with 
any differences between NE type releases. 

• Release Layer (1 250) • this is the most specific lay- 
er. It only Implements the differences between re- 
leases of a certain NE type. Most of these differenc- 
es can normally be handled statically through con- 
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figuration files so this layer should be fairty slim. 

Protocol independent commu'^ication with the NE Is 
handled through the generic gateway interface to be 
supported by ail gateways. 

Client Architecture (1300) 

Concept 

[0068] In the present invention, clients are light- 
weight: they handle nothing but presentation data and 
should therefore per definition be NE / protocol inde- 
pendent. They are of course function dependent, which 
could in fact be seen as NE dependence if a particular 
function Is only available in one particular NE. This is 
however not part of the definition of NE Independence 
as used throughout this document. Only handling pres- 
entation data means that no interpretation may be done 
of any attribute values retumed by the sender other than 
translate those values into user friendly, language de- 
pendent strings. 

[0069] NE dependence however occurs when 100% 
manageability needs to be provided over a strongly 
typed IDL Interface. A strongly typed interface is an in- 
terface where all functionality is available as specific 
functions with a specific set of typed arguments (hard- 
coded function signature). A weakly typed IDL interface 
provkles a generic execute() function that takes an ac- 
tion ID and a namevalue-pair sequence as arguments. 
In case of a weakly typed interface. 1 00% manageability 
can still be achieved without t>ecoming NE dependent 
in two ways: 



35 • 



the server albws a client to discover the supported 
functionedity of the objects it manages. 

the client reads the supported functionality (includ- 
ing the function's required parameters and their da- 
ta types) from configuration files. 



The navigation interface allows the client to build up its 
name space (navigation tree) without any knowledge 
about the NEs in its view. It also allows the client to dis- 
cover the functionality provided by those NEs. Using the 
navigation interface, building up the name space be- 
comes as easy as browsing a file structure. 
[0070] GEM uses both types of interfaces: each do- 
main server (optionally) publishes its own strongly typed 
interface and all domain servers share the navigation 
Interface which is weakly typed. 

Architecture 

[0071] The Client Architecture (1 300) as illustrated in 
FIG. 13 looks very similarto the EMS Applk:ation Server 
Architecture (0500) illustrated in FIG. 5. At the client 
side, the ptug-ln concept is also applied but here the 
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plug-in components are commonly referred to as "snap- 
in'* components. 

[0072] The Client Snap-In Framework (1310) allows 
for subcomponents (views) (1 320) to be plugged into the 
system. This component takes care of initializing the 
browser (Navigation Tree View) through the dynamic 
loading of the snap-ins listed in a configuration file 
(1311). Each snap-In initializes its root node, which cor- 
responds to the root node of the corresponding server- 
side plug-in. This is suffk^ient for the framework to be 
able to discover the rest of the name space including 
the functionality supported by each entity In the name 
space. 

[0073] Domain Views (Snap-Ins) (1 320) provide spe- 
cific NM functionality for their domain. Each Domain 
View (1321, 1322, 1323. 1324, 1325, 1326, 1327, 1329) 
has Its own name space that is nothing more than a re- 
stricted view on the overall Object Model. Multiple dif- 
ferent views can share objects. Each Domain View has 
a corresponding server-side Domain Manager (0520). 
[0074] Standard Generic Servtees (1330) are a col- 
lection of services available to all domain views (1 320). 
[0075] The Persistency Service (1 331 ) provides a re- 
pository for persistent data like common configuration 
files and storage of user preferences (1 332). 

The Event Manager (1 333) listens for autonomous 
messages coming from the event service and updates 
the model accordingly. The Model uses the event man- 
ager's servbes to register for object creation, object de- 
letion and attribute value change notifications. 
[0076] The Controller (1334) makes sure all views on 
the model are kept up to date by applying the model- 
viewcontro Her design pattern. It supports multiple views 
on the same data. Each modeled object maintains a ref- 
erence count so that infonnation can be garbage col- 
lected In the model as soon as nobody is still visualizing 
that data. 

[0077] The Commander (1335) provides the views 
with the interface towards the server. It makes the IDL 
layer Invisible to view implementers. This object pro- 
vides an API which is basically a 1 -to-1 mapping from 
the functionality defined on the IDL interface with the 
difference that for each available function a synchro- 
nous and an asynchronous version is available. The 
Commander object intercepts the responses to each re- 
quest In order to keep the M IB up-to-date without client- 
side development effort and to act as a cache for sut>- 
sequent requests. The Commander object only needs 
to be extended for the optional specific interface sup- 
ported by some domain servant. 
[0078] The Garbage Collector (1336) is a configura- 
ble component that removes objects from the MIB, 
based on their reference count. The gart>age collector 
can be configured to run automatically at certain inter- 
vals, manually or when the number of garbage collect- 
able objects reaches some predefined (configurable) 
value. 

[0079] The Caching Sen/ice (1 337) is a configurable 



component that artificially keeps the reference count 
above 0 for objects that are not currently being dis- 
played, but are good candidates for becoming vsible 
again in the near future. The caching service has acon- 

5 figurable View stack size. Whenever a view becomes 
invisible (replaced by some other view), it Is pushedonto 
the View stack. When a view drops off the stack, all of 
its objects are being invalidated (reference count set to 
0) so that they become food for the garbage collector. 

10 [0080] The Common Object Model (1338) is a tran- 
sient collection of objects organized in a tree structure. 
The collection of all objects in this Model is the overall 
name space. The model is built up withoutany program- 
ming effort required from the view implementers. The 

f ^ model acts as a cache for subsequent requests tor the 
same information. A view implementer doesnt know 
when a request for infomiation was satisfied locally or 
remotely. The model also doesnt require any user Inter- 
vention for keeping its infonnation up-to-date. Event 

20 registration is done dynamically based on what is cur- 
rently being stored in the model and therefore what is 
currently being displayed somewhere. The actual ob- 
jects stored in the model are fully customizable through 
user-supptied object factories. 

Exemplary System Deployment (1 400) 

[0081] While there are many possible deployment 
scenarios utilizing the present invention, several are 

30 preferred. An exemplary embodiment of one such de- 
ployment (1400) is illustrated in FIG. 14. This example 
may in many circumstances represent the 'normal" de- 
ployment situation. This means that the setups de- 
scribed here are not the only "working" ones, but that 

^ they are the "desired" ones in terms of expected per- 
formance and added value In many practical systems 
implementing the present invention. 
[0082] The optimal implementation of the present in- 
vention permits one GEM server per host to have an 

40 unlimited number of clients. These clients are either 
GEM GUI instances, pmtocol adapters towards external 
applications or higher level NML applicatk)ns. Each cli- 
ent typtoaily talks to just one server. The interface be- 
tween client and server is CORBA based and a client 

45 knows how to contact the server by means of the Nam- 
ing Service. The lOR of the Naming Service is set In a 
client-skie (and server-side) configuration file (ORB. 
properties). The Naming Service can be running on the 
same machine or on a remote machine in the same net- 

so work. 

[0083] Multiple instances of GEM servers can co-exist 
on the same machine (1 41 0, 1 430) and each server typ- 
ically manages multiple NEs (1411). Each NE should 
however be managed by at most one GEM server 
S5 (1412), while at the same time, another type of manager 
Is allowed to operate on the same NE (e.g.. TL1 termi- 
nal) (1421). One GEM server consists of multiple do- 
main servers (plug-in components) which are all regis- 
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tered with the Naming Service and therefore can be dis- 
tributed across multiple machines (1431) in the same 
networl<. 

Naming Sen/ice Registration / Naming Policy (1500) 

[0084] A detailed technical description of the Naming 
Sen/ice can be obtained by referring to the CORBA 
Standard Services documentation piie Common OI> 
ject Request Broicer: Architecture and Specification" at 
ftp://ftp.omg.org/puWdocs/formal/98-1 2-01 .pdf ). This 
section only explains how the Naming Service is being 
used in the context of the present invention. 
[0085] FIG. 15 illustrates an exemplary embodiment 
of the Naming Policy (1500). The figure shows an ex- 
ample in which two (2) GEM /Vppllcation Servers (EMI^s) 
exist. Their names ("G EM_1 " and "GEM.Z") correspond 
to the NeGroupId as used by PNM (0302) that uniquely 
identifies a group of NEs with a certain EMS. The "Ses- 
sionManager^ object reference is the entry point for ol> 
taining references (lORs) to domain managers. 
[0086] The object references associated with "Net- 
workAdmin", "NetworkSun^elllance" and "AlamiSyn- 
chronizer" are required by the ALMAP components AS 
and PNM. Their exact names are typically defined in an 
IDL definition file. 

[0087] AS also requires the name of the channel on 
which alamis are being sent, to be 
"XTSSEventChanner. PNM requires the name of the 

channel on which state changes are being sent, to be 
'*X721EventChanner'. Similarly, these two identifiers 
are typically defined in an IDL definition file. 

N£ IV^anagement 

[0088] N E Management is the process of adding N Es 
to the network, removing NEs from the network and 
making the NEs available or unavailable for manage- 
ment operations. All of these operations are initiated 
from the Physical Network Management (PNM) (0302) 
application user interface. 

NE States 

[0089] There are a number of states an NE can be In: 

• Communicatk>ns state - a read-only state attribute 
that Informs the manager that the NE is reachable 
over the network or not. In the first release of GEM 
this state is mapped onto the operational state. 

• Operational state - a read-only state attribute that 
informs the manager that the resource is operation- 
al or disabled. A disabled resource Is unavailable 
for management operations. 

• Administrative state - a readAwrite state attribute 
that Informs the manager that the resource is 
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locked, unlocked or shutting down. Locking a de- 
vice makes it unavailable for management opera- 
tions. 

5 • Supervision state - a read/Write state attribute that 
informs the manager that the server is logged into 
the network element (supervised) or not (declared). 
There are also 2 transitional states: supervising (in 
the process of logging in) and unsupervislng (in the 

10 process of k>gglng out). Practically, a supervised NE 
reports alarms to the manager, while a declared NE 
doesnt. 

• MIB alignment state - a read-only state attribute that 
IS infomns the manager that the data he Is managing 

might be stale (misaligned). The data is up-to-date 
when the state is aligned. 

Any changes to these states are reported as state 
20 change notifications. PNM is one applk^ation that regis- 
ters for these state change events. Any attempt by a 
manager to perform operations on a resource that is un- 
available will by answered with an InvalidState excep- 
tion. 

25 

AddNE 

[D080] As mentioned previously, at system startup the 
list of managed NEs is read from persistent storage. 
90 Once the system is running, NEs can be added via the 
PNM user interface. The information entered is: 

• NE name (logical name) 
35 • NE type 

As PNM doesnt provide a way to specify the NEs pro- 
tocol, this information needs to be read from a server 
side configuration file that provides the mapping from 

^0 NE type to NE protocol. 

[0091] PNM generates an internal identification for 
the NE. This Identification cannot be modified, as op- 
posed to the logk^al NE name. Clients work with the iog- 
toal NE name, while the server worl^ with the internal 

45 Identification. 

[0092] The fottowing steps are perfonned: 

• The NE*s name (logtoal and Interned) and type is 
added to the persistent storage. 

50 

• The NE's type is used to lookup the NE's protocol 
and supported domains. 

• The object factory is instructed to build an Ne<Do- 
ss main> object for each domain supported by a net- 
work element of the given type. 

• These Ne<Domaln> objects are added to the Ne 
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object's plug-in map (key domain identifier, value 
= object pointer). 

• The NE spedfic mapping dictionary is loaded. The 
name of the dictionary is <vendor>/<neType>/ 
<neRelease>/<protocol>.properties. This diction- 
ary contains the mapping Infomnation for all do- 
mains so it is stored in the NE object rather than In 
the domain specific NE<Domain> objects. (Note: 
the Dictionary object Iceeps a static reference count 
so that it needs to be built only once for all NEs of 
the same type; deleting an N E object then only dec- 
rements this reference count instead of removing 
the dictionary object). 

No connection is being established with the NE during 
this step. 

Remove NE 

[0093] NEs are removed from the system via the 
PNM-USM Interface. The following steps are per- 
formed: 

• The Ne object is deleted and by consequence all 
domain specific Ne<Domain> objects are deleted 
as well. 

• The NE's Infonnation is removed from persistent 
storage. 

Note: as JAVA is the programming language of choice 
in the GEM project, the finalizeQ method needs to be 
tnrtplemented by all NE objects in order to perform the 
necessary cleanup, i.e. reverse the steps done in the 
addNE step. 

Start Supervision 

[0094] This is the process of making the given NE 
available for management. This operation is started 
through the PNM-USM interface. The following steps 
are performed: 

• The connection to the NE is established. 

• The server is logged into the NE. 

• All domain servers are notified of this event by call- 
ing their startSupervislonQ function. 

See elsewhere in this document for the details of estab- 
lishing a connection with the NE. 

Stop Supervision 

[0095} This Is the process of making the given NE un- 
available for management. This operation is started 
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through the PNM-USM interface. The following steps 
are performed: 

• The server is logged out of the NE. 

5 

• The connection with the NE is broken down, but the 
NE's Information is not destroyed. 

[0096] AH domain servers are notified of this event by 
10 calling their stopSupervision() function. 

NE Connection Management 

[0097] NE Connection Management includes the 
IS process of establishing connactions with the NE and 
tearing down those connections. It also includes the de* 
tectlon of broken connections and automatically recon- 
necting. Login and logout are also categorized under 
this header. 

20 

Connect to NE 

[0098] From GEM's point of view, the connection to 
an NE is a TCP/IP connection (socl<ot). The actual con- 
25 nection protocol used by the NE itself can be different, 
e.g. X.25, ACSE, RS232), the complexities of which are 
hidden by the communications server. The following 
steps are performed during the connection process: 

30 • The supervision state is set to ACTIVATING. 

• The address, user name and password are read 
from the persistent storage (obtained from PNM 
during the setAddressQ action) and a socket con- 

35 nection is created with their values. 

• A new thread is started for monitoring incoming au- 
tonomous messages or command replies. 

40 • When all the previous was successful, the opera- 
tional state of the NE is set to ENABLED. 

• The logout procedure is started. This is done to 
cope with the situation where the previous session 

^ was not ksgged out; I.e. the session Is still active. 
The server cannot re-attach to a previous session. 

• The login procedure is started. 

so • If the login procedure was successful, the startA- 
lignmentQ method is called on all domain roots. 

When all domain roots successfully finished aligning, 
the MIB alignment state is set to ALIGNED and the su- 
55 pervislon state is set to SUPERVISED. If logging in 
failed, the operational state is set to DISABLED, the MIB 
alignment state is set to MISALIGNED, the supen/ision 
state is set to DECLARED and the re-alignment thread 
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is Started. 

Disconnect from NE 

[0099] The following steps are perfomned: 

• The supervision state is set to DEACTIVATING. 

• The logout procedure is started. 

• The socket is destroyed. 

• The operational state is set to DISABLED and the 
MIB alignment state is set to MISALIGNED. 

• The supervision state is set to DECLARED. 
Login to NE 

[0100] Once the physical connection Is established 
with an NE, the user still needs to login before opera- 
tions can be done on It. All domain servers use the same 
connection and user account The following steps are 
perfomned: 

• The TL1 command for logging In Is built by using 
the NE specific TL1 dictionary. 

• The command is sent to the NE. 

• if the command failed, a ProxyEn'or exception is 
thrown and the operational state is set to DISA- 
BLED. 

Logout 

[0101] Before closing a physical connection, the user 
needs to be togged out from the system first. Discon- 
necting without logging out first will work but is not clean. 
The following steps are perfomned: 

• The TL1 command for logging out is built by using 
the NE specific TLl dictionary. 

• The command Is sent to the NE. 

• If the command failed, a ProxyError exception is 
thrown. 

Connection Lost / Reconnect 

[01 02] As with every distributed ciient^server architec- 
ture, the connection between client and server can 
break down ortemporarily become unavailable. This sit- 
uation Is detected by means of 2 threads: 

• the communications polling thread - this thread de- 
tects the loss of communication between the GEM 



Application Server (role of client) and the Network 
Element (role of server). 

• the re-alignment thread - this thread continuously 
5 checks the communications state and MIB align- 
ment state of this NE 

Loss of communication is detected by sending a ping 
request on regular time intervals. In the TLl worid. ping 

10 takes the fomn of RTRV-HDR. When the ping request is 
left unanswered within a set timeout, the MIB Alignment 
State Is set to MISALIGNED and when a lO exception 
is received the communications state is set to DISA- 
BLED. When the communications state becomes 0\S' 

IS ABLED, the communications polling thread is stopped. 
[01 03] The re-alignment thread starts the re-connect 
process when the communications state is not ENA- 
BLED and starts the alignment process when the MIB 
alignment state is MISALIGNED. The general proce- 

5o du re f o r this re-oo n n ecti o n is as follows : 

1 . try to reconnect to the same address; 

2. If failing again, try different address ... Exemplary 
ss CGA Interface Components (1700) 

[0104] While one skilled in the art will quickly recog- 
nize that there are a plethora of methods available to 
implement embodiments of the present invention, it is 
30 instructive to view one exemplary embodiment of the 
CGA architecture and a sample of some of the interfac- 
es that ft might penmit. To this end. FIG. 1 7 illustrates an 
exemplary connpiement of CGA interface modules 
(1700) that are described in detail in the following see- 
ds tions 

AddNEto EMS (1800) 

[0105] A generalized flowchart for adding a network 
40 element to the element management system is illustrat- 
ed in FIG. 18 (1800). The method generally follows the 
following steps as detailed in FIG. 18: 

1 . References to the network element protocol (P), 
49 network element type (T), and network element re- 
lease (R) are defined (1801). 

2. Create a new network element managed object 
instance in model (N) (1802). 

50 

3. Instantiate the gateway/proxy G for a given P, R, 
and T and store a pointer to it in N (1 803). 

4. Find the protocol dictionary forT and R in the el- 
95 ement management system's dictionary manager 

(1804). 

5. If the dictionary Is found (1605), proceed to step 
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10. 

6. Build a new dictionary for T and R and store a 
pointer to it in the dictionary manager (1806). 

7. Retrieve network element type and release spe- 
cific protocol information (1 807). 

8. If step 6 is successful (1B08), then proceed to 
step 10. 

9. Throw a Proxy Error exception (1809) and exit. 

10. Increment reference count to the protocol dic- 
tionary in the dictionary manager (1810). 

11 . Store a pointer to the protocol dictionary in the 
new gateway/proxy Instance (1811). 

[0106] One skilled in the art will recognize that these 
steps may be changed in order or function with no loss 
of generality. 

Remove NE from EMS (1900) 

[0107] A generalized flowchart for removing a net- 
work element from the element management system is 
illustrated in FiG. 19 (1 900). The method generally fol- 
lows the foOowing steps as detailed in FtG. 1 9: 

1 . Reference to the network element (N) is defined 
(1901). 

2. Decrement the reference count to N's protocol 
dictionary in the dictionary manager (1902). 

3. If the reference count is not zero (1 903), then pro- 
ceed to step 5. 

4. Remove the protocol dictionary from the diction- 
ary manager and free up memory (1904). 

5. Delete the network element reference N (1 905). 

[0108] One skilled In ihe art wlli recognize that these 
steps may be changed in order or function with no loss 
of generality. 

Configure Gateway (2000) 

[0109] The protocol gateway doesn't have any NE 
specific knowledge built in. The gateway however needs 
to be configured for each network element type. This 
method instructs the gateway to process the protocol 
dictionary for the given network elennent type and re- 
lease. Internaity, the gateway will build up a map of com- 
mand identifier to protocol template strings and a map 
of command identifier to rules to parse attribute values 
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out of the command response. 

[01 10] A generalized flowchart for configuring a gate- 
way is illustrated in FIG. 20 (2000). The method gener- 
ally follows the following steps as detailed in FIG. 20: 1 . 

s 

1 . Instruct the gateway on how to process the pro- 
tocol dictionary for the given network element type 
and release (2001). 

10 2. Build up a map of command identifiers to protocol 
template strings and a map of command identifiers 
to rules to parse attribute values out of the com- 
mand response (2002). 

One skilled in the art wilt recognize that these steps 
may be changed in order or function with no loss of 
generality. 

Set NE Address (2100) 

[01 1 1 ] There is one gateway instance per network el- 
ement. The NE address is set by this function. 
[0112] A generalized flowchart for setting the network 
element address is illustrated In FIG. 21 (2100). The 
method generally follows the following steps as detailed 
in FiG. 21 : 

1 . Set/save the network element address for use by 
other functions (2101 ). 

[0113] One skilled in the art will recognize that these 
steps may be changed in order or function with no loss 
of generality. 

Connect to NE (2200) 

[0114] This method establishes a socket connection 
with the network element on the address set by the pre- 
vious function. The function starts by setting the network 
element's communteations state to "connecting". Then, 
the function tries to open a socket connection with the 
NE. If this falls, the communications state is set to "dis- 
connected" and an exception is thrown. If the socket 
connection was successfully established, the communi- 
cations state is set to "connected**. 
[0115] Agenerallzedftowchartforconnectiontoa net- 
work element Is Illustrated in FiG. 22 (2200). The meth- 
od generally follows the following steps as detailed in 
FIG. 22: 

1 . References to the network element (P), network 
element address (A), and gateway/proxy (G) are 
defined (2201). 

2. The network element address is set in G (2202). 

3. Set the communications state in N to "connect- 
ing" (2203). 
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4. A socket connection to the network element on 
address A is established (2204). 

5. If the connection was successful (2205), then 
proceed to step 7. 5 

6. Throw a ProxyComm Error exception (2206) and 
exit. 

7. Set the communications state in N to 'con nected" io 
(2207). 



[0116] One skilled in the art will recognize that these 
steps may be changed in order or function with no toss 
of generality. 



Disconnect from NE 

[01 1 7] This method closes the socliet connection with 
the network element associated with this gateway. The 
function start by setting the network element's commu- 
nications state to "disconnecting". Then, the function 
closes the socket connection and sets the communica- 
tions state to "disconnected". 

[01 18] A generalized flowchart for disconnecting from 
a network element is illustrated in FIG. 23 (2300). The 
method generally follows the following steps as detailed 
In RG. 23: 

1 . Reference to the network element (P) is defined 

(2301). 

2. Set the communk:ations state In N to "disconnect- 
ing" (2302). 

3. Close the socket connectton to the network ele- 
ment (2303). 

4. Set the communtoatk^ns state In N to "disconnect- 
ed" (2304). 

[01 19] One skilled in the art will recognize that these 
steps may be changed in order or function with no loss 
of generality. 

Check Connectivity / Ping Cycle (2400) 

[01 20] O nee the server is logged in to the network el- 
ement, a polling cycle continuously monitoring the re- 
sponsiveness of the network element, Is started. (The 
server logs In to the network element by sending the 
LOGIN command using the "send command to NE" 
function). This function uses a timer to periodically send 
a command with limited overhead (e.g. RTRV-HDR in 
case of TL1 NEs) to the network element. When the 
command comes back within a certain configurable time 
interval, the timer is reset, if the command doesn't come 
back within this time interval, a communications prob- 
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lem was detected and flagged. 
[0121] A generalized flowchart for perfomning this 
connectivity check / ping cycle is illustrated in FIG. 24 
(2400). The method generally follows the following 
steps as detailed in FIG. 24: 

1 . References to the ping cycle timeout (duration) 
(P), gateway/proxy (G), timer (T), and request time- 
out limit (L) are defined (2401 ). 

2. A timer is reset/started (2402). 

3. Send requests (2403) reset the timer in step 2. 

4. Timer T is incremented until it is greater than P 
(2404). 

5. If the timer has expired or T>P, then the timing 
process is terminated (2405). This is an asynchro- 
nous event linked to step 3. 

6. A ping command is sent (2406). 

7. If a response is received within time limit L (2407), 
then processing proceeds to step 2. 

8. A communications problem is flagged as an error 
(2408). 

[0122] One skilled in the art will recognize that these 
steps may be changed in order or function with no loss 
of generality. 

Register Autonomous IVIessage Callback (2500) 

[01231 Alannris. database change messages, thresh* 
old crossing alerts, etc. are all examples of autonomous 
messages. These messages are spontaneously sent by 
the NE to the server. As this happens asynchronously, 
the server needs to register a callback with the gateway. 
Each time an autonomous message is received by the 
proxy, the proxy calls the handleMessageO method de- 
fined in callback object for all registered callbacks. 
[0124] A generalized flowchart for registering auton- 
omous message callbacks Is Illustrated In FIG. 25 
(2500). The method generally follows the following 
steps as detailed In FIG. 25: 

1 . Provide support for autonomous messages that 
are spontaneously sent by the NE to the server 
(2501 ). 

2. Register a callback with the gateway (2502). 

3. Each time an autonomous message is received 
by the proxy, the proxy calls the handleMessageO 
method defined In the callback object for all regis- 
tered callbacks (2503). 
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[0125] One skilled In the art will recognize that these 
steps may be changed in order or function with no loss 
ot generality. 

Send Command to NE (2600) s 

[0126] This function sends the command associated 
wAh the givon command Identifier and the given comv 
mand-input arguments to the object identified by the giv- 
en FDN The command also takes the list of expected io 
output arguments as input. The function first checks if 
the communications state is currentiy "connected". If 
nor an exception is throNvn. The function searches for 
the given command identifier in the protocol dictionary. 
II the command identtf ier was not found, the Command- is 
NotFound exception is thrown. Else, the command tem- 
plate HSSooAtcd with the command identifier is retrieved 
from the protocol dictionary. The function then replaces 
the p Mcchoklcrs m the command template with the giv- 
en vriiuci* for the corresponding attributes. The function ^ 
then generates a unique (sequential) number that wiil 
act as it>c unique identification for the command execu- 
tion. The ptricchoidcr for the CTAG attribute is replaced 
by th:s i.nicuc number. The command response sends 
this unique number back, so that the system can corre- 2S 
lato lie response with a command In a multi-threaded 
environment wuh asynchronous comnnand executions. 
The function sends the command over the socket con- 
ned ion ;4nd stores the command in a correlation map. 
The curren: ihrcad is put to sleep. 30 
[0127] In the meantime, anotherthread Is continuous- 
ly monitonrig the socket for incoming messages (auton- 
omous mcssaQOS and command responses). When a 
message comes in. a sequence of characters is read 
from the socket until a predefined temfiination character ss 
is read (*:' tn case of TL1). The termination character 
defines Ihc end of a message. The message type is ex- 
tracted. This type identifies the message as an autono- 
mous message or as a command response. If the mes- 
sage <s an autonomous message, the registered call- 40 
back's handlcMcssageO method is called (see reglster- 
CallbackO function) for processing. If the message cor- 
responds 10 a command response, the correlation tag 
is extractoo from it and the correlation map is searched 
for the presence of Ihts tag. If the tag Is not present, this ^ 
message is discarded. If the tag was found, the corre- 
sponding oonvTMnd object is retrieved from the map. 
Thecommantfs response is added to the command ob- 
ject and all sleeping threads are notified. This wakes up 
a randomly selected send-thread. The awoken thread so 
checks whether his command object now has the re- 
sponse set. If so. the function returns the response. Oth- 
erwise, (ho thread is put back to sleep and the next ran- 
domly selected send-thread is awoken until no more 
sendthreads are available. 55 
[0128] A generalized fk>wchart for sending com- 
mands to a nchivork element is illustrated in FIGs. 26-30 
(2600). The method generally follows the following 
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steps as detailed in FIGs. 26-30: 

1 . References to the networlc element (N). gateway/ 
proxy (G), command identifier (C), argument list (A), 
and FDN template arguments with given argument 
values (A) (2709).of the target object (F) are defined 
(2601). 

2. If N is connected (2602), proceed to step 4. 

3. Throw a ProxyComm Error (2603) and exit, 

4. Send the command to the network element 

(2604) . 

5. Lookup the request template corresponding to 
the command Identifier C in the protocol dkrtionary 

(2605) . 

6. Read the protocol dictk>nary (2606) to implement 
step 5. 

7. If command C was found, proceed to the send 
command/store result flowchart of FIG. 27 (2700). 

8. Throw a CommandNotFound exception (2608). 

9. Substitute command 

1 0. Insert correlation tag as the command argument 

(2710) . 

1 1 . Send the command over the socket connection 

(2711) . 

12. Store the request object In the correlation map 
index by correlation tag (2712). 

13. Utilize a command correlation map to imple- 
ment step 12 (2713). 

14. Execute a sleep request thread (2714) of FIG. 
30. 

[0129] One skilled In the art will recognize that these 
steps may be changed In order or function with no loss 

of generality. 

Retrieve Command Response From NE (2800) 

[0130] A generalized flowchart for retrieving com- 
mand responses from a network element is illustrated 
in FIGs. 28-30 (2600). The method generally follows the 
following steps as detailed in FIGs. 28-30: 

1 . Reference to the gateway/proxy (G) is defined 
(2801). 
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2. An entrypoint for thread loop cycling is defined 
(2802) 

3. Incoming response/ autonomous nnessage pack- 
ets are read (2803). 

4. Step 2 is repeated until a message terminator is 
received (2804). 

5. The message type Is extracted (2805). 

6. If the message is a response (2806), control is 
passed to the Correlate and Find Request Object 
entry in FIG. 29 of step 8. 

7. Otherwise, an autonomous message Is handled 

(2607). 

8. Ttie congelation tag is extracted and a pointer is 
obtained to the request from the command correla- 
tion map (2908). 

9. A command correlation map is used in the ex- 
traction process of step 8 (2909). 

10. If the requested object Is found (2910), control 
passes to step 12. 

11 . Otherwise, the message Is discarded (2911). 

1 2. The correlation tag Is extracted to obtain a point- 
er the request object from the command correlator 
(2912). 

13. The response is set in the request object (291 3). 

14. Alt sleeping threads are notified (2914) as indi- 
cated In FIG. 30 and the thread notify loop (2915) 
is activated in FIG. 26 (2802). 

[0131] One skilled in the art will recognize that these 
steps may be changed in order or function with no loss 
of generality. 

Processing Sleep Request Threads (3000) 

[01 32] Processing of sleep request threads associat- 
ed with sending and retrieving network element com- 
mands is illustrated in FIG. 30 (3000). 

Preferred System Context of the Present Invention 

[0133] While the present invention may be best ap- 
plied to situations in which telecommunications net- 
works are to be managed and maintained either locally 
or remotely using graphical user interface (GUI) based 
operator consoles, the present invention also has wida 
applicability in situations in which any type of hardware 



and/or software component in a computer network Is to 
be managed In a unifomri way with minimal software do- 
sign complexity and maintenance costs. 
[0134] The functional elements of the present inven- 

5 tion are widely applicable to situ ations invoh^ing multiple 
types of remote equipment sourced from a variety of 
hardware and software manufacturers. Since the 
present invention breaks the compile-time link between 
network element management and the tool used to per- 

10 form the management fu notion » this penmrts a wide va- 
riety of applications in situations where networks must 
be grown dynamically by adding hardware and soft- 
ware, but which must remain up and functional during 
this upgrade process. 

75 

Conclusion 

[0135] An Element Manager Common Gateway Ar- 
chitecture (CGA)sy6tem and method incorporating a cli- 

^ ent/server architecture in which a network Element 
Management System (EMS) takes the role of "client" 
and the protocol gateways/proxies take the role of "serv- 
er" has been diseased. The EMS defines all protocol- 
independent application logic while the gatewaye/prox- 

25 ies deal exclusively with protocol-specific knowledge. 
The Common Gateway Architecture (CGA) allows the 
application logic to be shared among protocols, using a 
protocol Independmt data model. A significant aspect 
of the software maintenance in EMS systems is that 

30 since network elements (NEs) use many different pro- 
tocols, there exists a difficulty and time lag associated 
with customizing a common network element manager 
for every networic element using a different protocol in 
a given system. Modifications to the system typically re- 

3S quire incofporatton of new code Into the network ele- 
ment manager with associated recompilatlon of the en- 
tire network element manager subsystem. The present 
Invention solves this problem by using a common gate- 
way architecture designed to be generic across different 

^0 types of NEs and different netivork protocols. This per- 
mits NEs to be added incrementally without recomplla- 
tion of the entire network element manager, thus reduc- 
ing overall software nnaintenanoe overhead. 
[0136] Although a preferred embodiment of the 

^9 present Invention has been Illustrated In the accompa- 
nying Drawings and described In the foregoing Detailed 
Description, it will be understood that the inventk>n Is 
not limited to the embodiments disclosed, but is capable 
of numerous rearrangements, modifications, and sub- 

so stitutlons without departing from the spirit of the inven- 
tion as set forth and defined by the following claims. 



Claims 

55 

1. An element manager common gateway architec- 
ture (CGA) system comprising: 
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(a) a gateway/proxy tayer means; 
wherein 

said gateway/proxy layer means translates ge- 
neric CGA commands to specific network ele- s 
ment protocols; 

said gateway/proxy tayer means translates 
specific network element protocols to CGA ob- 
ject and/or attributes; and io 

said gateway/proxy layer means permits bi-di- 
rectional communication between an element 
management system and a network element 
using said translations. ts 

2. The element manager common gateway architec- 
ture system of Claim 1 wherein said gateway/proxy 
layer means and said network element reside on 
separate nodes within a computer network. 20 

3. The element manager common gateway architec- 
ture system of Claim 1 wherein one or more com- 
ponents of said system is imptemented within an 
application programming interface (API). 

4. The element manager common gateway architec- 
ture system of Claim 1 wherein one or more com- 
ponents of said system is implemented within a web 
browser. 30 

5. The element manager common gateway architec- 
ture system of Claim 1 wherein said communication 
occurs over the Intemet. 

35 

6. The element manager common gateway architec- 
ture system of Claim 1 wherein one or more com- 
ponents of said system is implemented on a per- 
sonal computer (PC). 

40 

7. The element manager common gateway architec- 
ture system of Claim 6 wherein said personal com- 
puter (PC) utilizes a graphical user interface. 

8. The element manager common gateway archftec- 
ture system of Claim 7 wherein saki graphical user 
interface utilises a HP-UX^** operating environ- 
ment. 

9. The element manager common gateway archilec- 5C? 
ture system of Claim 7 wherein said gre^ihical user 
interface utilizes a LINUX™ operating environment. 

10. The element manager common gateway architec- 
ture system of Claim 7 wherein said graphical user 
interface utilizes a SOLARIS'^m operating environ- 
ment. 
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11. The element manager common gateway architec- 
ture system of Claim 7 wherein said graphical user 
interface utilizes a UNIX^^ operating environment. 

12. The element manager common gateway architec- 
ture system of Claim 7 wherein said graphical user 
Interface utilizes a Microsoft(6> Windows*^^ operat- 
ing environment. 

13. [System lnterface]The element manager common 
gateway architecture (CGA) system of Claim 1 
wherein said gateway/proxy layer means further 
comprises: 

(a) an add network element means; 

(b) a delete network element means; 

(c) an configure gateway means; 

(d) a set network element address means; 

(e) a connect to network element means; 

(f) a disconnect from network element means; 

(g) a check connectivity means; 

(h) a register autonomous message callback 
means; 

(i) a send command to network element means; 
and 

(j) a retrieve command response from network 
element means. 

14. The element manager common gateway architec- 
ture system of Claim 13 wherein said gateway/ 
proxy layer means and said network element reside 
on separate nodes within a computer network. 

15. The element manager common gateway architec- 
ture system of Claim 13 wherein one or more com- 
ponents of said system is implemented within an 
application programming interface (API). 

16. The element manager common gateway architec- 
ture system of Claim 13 wherein one or more com- 
ponents of said system is Implemented within a web 
browser. 

1 7. The element manager common gateway architec- 
ture system of Claim 13 wherein said communica- 
tion occurs over the Intemet. 

18. The element manager common gateway architec- 
ture system of Claim 13 wherein one or more com- 
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ponents of said system Is imp lamented on a per- 
sonal computer (PC). 

19. The element manager common gateway architec- 
ture system of Claim 1 8 wherein said personal conrt- s 
puter (PC) utilizes a graphical user interface. 

20. The element manager common gateway architec- 
ture system of Claim 1 9 wherein said graphical user 
inierface utilizes a MP-UX^^ operating environ- io 
ment. 

21. The element manager common gateway architec- 
lure system of Claim 1 9 wherein said graphical user 
interlace utilizes a LINUX^*^ operating environment, is 

22. The clement manager common gateway architec- 
ture system ol Claim 1 9 wherein said graphical user 
intcrf<4cc ulili/es a SOLARIS^^ operating environ- 
ricnl 20 

23. The cicnrMini manager common gateway architec- 
t jrc system ol Claim 1 9 wherein said graphical user 
intcn«>cc ulili/csa UNIX^M operating environment. 



25 



30 



24. The oiomoni manager common gateway archltec- 
t jrc system of Claim 1 9 wherein said graphical user 
intcrlMco ulili/es a Microsoft® Windows^^ operat- 
ing environment. 

25. IMoihod Base|An element manager common gate- 
way architecture (CGA) method comprising: 



(1) generating common gateway architecture 
(CGA) gateway/jproxy layer communications 33 
means between an element management sys- 
tem and a network element; 

(2) trar^lating generic CGA commands to spe- 
cific network element protocols through said ^ 
communjcation interface means; and 

(3) translating specific network element proto- 
cols to CGA object and/or attributes through 
said communication Interface means; 
wherein 

satd gateway/proxy layer means pemnits bi-di- 
roctional communication between an element 
management system and a network element ^ 
using said translations. 

26. The olomont manager common gateway architec- 
ture method of Claim 25 wherein said gateway/ 
proxy layer means and said network element reside 55 
on separate nodes within a computer network. 

27. The element manager common gateway architec- 



ture method of Claim 25 wherein one or more steps 
of said method is Implemented within an application 
programming interface (API). 

28. The element manager common gateway architec- 
ture method of Claim 25 wherein one or more steps 
of said method is implemented within a web brows- 
er. 

29. The element manager common gateway architec- 
ture method of Claim 25 wherein said communica- 
tion occurs over the Internet. 

30. The element manager common gateway architec- 
ture method of Claim 25 wherein one or more steps 
of said method is implemented on a personal com- 
puter (PC). 

31. The element manager common gateway architec- 
ture method of Claim 30 wherein said personal com- 
puter (PC) utilizes a graphical user Interface. 

32. The element manager common gateway architec- 
ture method of Claim 31 wherein said graphical user 
interface utilizes a HP-UX^*^ operating environ- 
ment. 

33. The element nnanager common gateway architec- 
ture method of Claim 31 wherein saJd graphical user 
interface utilizes a LINUX*^*" operating environment. 

34. The element manager common gateway architec- 
ture method of Claim 31 wherein said graphical user 
interface utilizes a SQL^RIS'^ operating environ- 
ment. 

35. The element nwinager common gateway architec- 
ture nnethod of Claim 31 wherein said graphical user 
interface utilizes a UNIX^^ operating environment. 

36. The element manager common gateway architec- 
ture method of Claim 31 wherein said graphical user 
interface utilizes a Microsoft(B» Windows^** operat- 
ing environment 

37. A connputer usable medium having computer-read- 
able program code means providing element man- 
ager common gateway architecture (CCA) function- 
ality, sakJ computer-readable program means com- 
prising: 

(1) computer program code means for gener- 
ating a common gateway architecture (CGA) 
gateway/proxy layer communications means 
between an element management system and 
a network element; 

(2) computer program code means for translat- 
ing generic CGA commands to specific network 
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element protocols through said communication 
interface means; and 

(3) computer program code means for translat- 
ing specific networl< element protocols to CGA 
object and/or attributes through said communi- 5 
cation interface means; 
wherein 

said gateway/proxy layer means permits bi-di- 
rectional communication between an element 
nrianagement system and a network element io 
using said translations. 

38. The computer usable medium of Claim 37 wherein 
said GUI development framework means and said 
data means reside on separate nodes within a com- 
puter network. 

39. The computer usable medium of Claim 37 wherein 
one or more steps of said functionality is implement- 
ed within an application programming interface ^0 
(API). 

40. The computer usable medium of Claim 37 wherein 
one or more steps of said functionality is implement- 
ed within a web browser. 

41. The computer usable medium of Claim 37 wherein 
said communication occurs over the Internet. 

42. The computer usable medium of Claim 37 wherein 30 
said medium is compatible with a personal compu- 
ter (PC). 

43. The computer usable medium of Claim 42 wherein 
said computer code means utilizes a graphical user 35 
interface. 

44. The computer usable medium of Claim 43 wherein 
said graphical user interface utilizes a HP-UX'^** op- 
crating environment. ^ 

45. The computer usable medium of Claim 43 wherein 
said graphical user interface utilizes a LINUX^^ op- 
erating environment. 

43 

46. The computer usable medium of Claim 43 wherein 
said graphical user interface utilizes a SOLARIS^** 
operating environment. 

47. The computer usable medium of Claim 43 wherein so 
said graphical user interface utilizes a UNIX^^ op- 
crating environment. 

48. The computer usable medium of Claim 43 wherein 
said graphical user interface utilizes a Microsoft® 55 
Windows^"" operating environment. 
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